A transaction is a set of operations that transforms the data from one state to another. A transaction typically includes a section of program code or a set of program instructions. In a transactional memory system, the concurrent transactions are speculatively executed and only those transactions are committed that are non-conflicting. A conflict may occur when two or more concurrent transactions access similar pieces of data, such as word, block, object, etc. from a memory, and at least one memory access is a write access. Transactions may be unable to succeed for a number of other reasons. For example, the transactional storage accesses may exceed the capacity of the conflict detection mechanism or an instruction that is illegal in a transaction may be found in the transaction. In the following description, these additional reasons are understood to be included in descriptions of behavior generally related to conflicts, although they are a distinct set of reasons that transactions do not succeed. Transactional memory systems may abort some transactions in order to resolve conflicts among concurrent transactions. One common challenge in the design of transactional memory systems is the asynchronous occurrence of some transaction abort conditions relative to the execution of the transaction itself. This can present difficulties for programmers coding the transactions and later trying to understand why a transaction did not succeed, for example if multiple transaction abort conditions occur, or when a transaction abort condition occurs due to an instruction that was executed much earlier in the transaction, or due to an instruction that has been executed but not committed at the time that failure handling occurs. It could also present difficulties for designers, if all asynchronous conflicts were required to be manifest before any subsequent instructions were executed.
The changes made by a transaction to a memory are validated, and if validation is successful, the changes are made permanent, and the transaction is referred to as a committed transaction. If a transaction cannot be committed due to conflicts, it is aborted, and any changes made by the execution of the instructions in the transaction are rolled-back. The aborted transaction is re-executed from the beginning until it succeeds.
The transactional memory system can be implemented in the form of hardware or software, or a combination of both. Hardware transactional memory systems include modifications to the processors, caches, and bus protocols to support transactions. Software transactional memory system provides transactional memory semantics in a software runtime library.
In software that includes speculative transformations, often the code includes one or more transactional abort instructions, the execution of which is based on the result of a condition specified in a previous instruction. For example, in one exemplary speculative optimization on a program that does numerical calculations, code may be optimistically generated to perform operations using low-latency fixed point instructions, on the prediction that no divisions will be performed that generate a remainder. In the event that a division does produce a remainder, the transaction may be aborted based on the presence of a remainder, and a floating point version of the code may be executed.
In another example, an array bounds check may be performed, in which it is detected whether a variable is within some bounds/limits. It is particularly relevant to a variable used as an index into an array to ensure its values lies within bounds of the array. The transaction may be aborted in a current instruction based on comparison of the variable with upper/lower limits in a previous instruction. However, performing bound checking may be quite time consuming, especially when there is a large number of variables on which bound checking needs to be performed.
The fixed point arithmetic and array bound checking are just examples, which include a transaction abort instruction based on a previous instruction. There could be many other transactions which include a transaction abort instruction based on a previous instruction. Thus, a code which includes a large number of transaction abort instructions is quite large in size as the transaction abort instruction is always present in a code along with other instruction. Hence, there is a need for a solution which reduces the size of the code which contains transaction abort instructions. There is also a need for ease of coding, more efficient cache/storage use to increase performance.
In light of the foregoing discussion, there exists a need to provide a solution that overcomes the above mentioned problems associated with the prior art alternatives.